Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/1111

Internet Message Format | 1994-08-27 | 4KB

Date: Fri, 29 Jul 1994 00:46:13 -0400 (EDT)
From: Timothy Miller <[e-mail]>
Subject: Amodal Dialogs
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-Id: <Pine.3.87.9407290013.C17722-0100000@grad>
Mime-Version: 1.0
Precedence: bulk


Hollis:

]Whoever (Gee, I like anonymous messages):
]-----------------------------------------
]> No, it is NOT that simple.  When you click to top a window, the message
]> does not get sent until you let go of the button.  You can hold the
]> button all day, and the window won't get topped until you let go of the
]> button.
]
]Have you even TRIED doing what I've proposed?  Sure, the message may not
]be sent until you let go of the mouse button, but you can surely trap it.
]Have you *tried* doing this?
]
]Oh, and I hate to tell you...  *YES IT IS THAT SIMPLE*

YES!  I have tried it!  I've been doing it ever since the first time
someone mentioned this as a technique for taking clicks for background
windows.

And I very much like to tell you:  *NO IT IS NOT THAT SIMPLE*

And here's why.....


To everyone:

I figured out how to do drags and the like for background windows, and
I'm surprised I didn't think of it earlier.  Earlier today, I made the
above comment about the WM_TOPPED event not getting to the window until
after the button is released.  This is not correct.

It appears that evnt_multi will not return to the program for the NEXT
evnt_multi if the mouse button is still held down -- OR -- event_multi
will not continue to send WM_TOPPED messages for the window clicked on
while the button is still held down.

Now knowing this, I had a background window that I had flagged as
untoppable and background active (using flags in my program... I'm using
regular TOS, so there is no WF_BEVENT).  When the WM_TOPPED message would
come to my program, I would get the mouse position and pass the correct
information to the routine that handles mouse events for the dialog.
This worked fine, except that if I PRESSED the mouse button (rather than
clicking it), then the program would no longer get any more WM_TOPPED
messages for that window until I clicked somewhere outside of that window.

This frustrated me, so I tried a few solutions.  First, I put a simple
loop after the mouse-event routine came back to wait until the button was
let up before returning.  This did not help.

Then I tried putting that loop BEFORE the call to the mouse-event
routine.  This caused clicks to be sent only after the mouse was let up,
but it solved the problem of the window not getting any more WM_TOPPED
messages.

It was at that point that I realised that if I were to continue to
simulate mouse events as long as the button was held down, then I
wouldn't have to worry about evnt_multi not returning... I wouldn't be
using evnt_multi until after the button had been let up.

This worked great.  I could drag sliders and everything.

But there is a problem with form_button and objects marked as
selectable.  As you know, when a selectable button is clicked,
form_button does not return until the button is let up.  What I want to
know is how is the use of form_button when a button is PRESSED (not
simply clicked) preventing further WM_TOPPED messages from being sent to
my application for that window, and how do I solve this problem?

Everything would be just dandy if something weren't preventing these
WM_TOPPED messages from being sent.  Other messages seem to get sent just
fine, and the problem clears up if I click anywhere outside of the window
in question... until I press a button again.


Ta.